A Pluralist Approach to Interdomain Communication Security

The best way to support secure communication in the Internet is the subject of much debate. The role of secure routing, in particular, has received considerable attention. The debate has been dominated by a “purist” philosophy that advocates the ubiquitous deployment of a secure version of BGP. The purist approach seems natural, if not mandatory, since BGP is the glue that holds the disparate parts of the Internet together. Purist solutions are advocated in public forums, such as the RPSEC working group of the IETF [2] and the North American Network Operators Group [3]. In fact, the debate focuses primarily on which secure routing protocol should be adopted (e.g., S-BGP or soBGP) [4], rather than whether a single solution should prevail. In fact, the Internet policy community has also discussed the possibility that the U.S. government might mandate S-BGP deployment [1]. Although ensuring that routing-protocol messages are authorized is clearly useful, we find the purist approach discomforting, for both economic and technical reasons: Ubiquitous deployment would require the cooperation of more than 20,000 Autonomous Systems (ASes). The large size of the group prevents market forces from driving deployment, implying the need for government regulation—an outcome that may be both hard to realize (due to the global nature of the Internet) and undesirable (since it may stifle innovation). Smaller groups of like-minded ASes are much more likely to deploy a security solution. Market forces can drive smaller-scale deployments, either because one (presumably large) AS is willing to bear a large part of the cost, or because adoption by some ASes has a noticeable effect on other members of the group. Groups benefit from deploying customized security solutions. No one interdomain security solution satisfies all of the security objectives, and the choice of a secure routing protocol is just one part of any solution. Different groups may want to strike different trade-offs, based on their customer requirements and deployment costs. Instead, we argue for a “pluralist” approach that enables graceful coexistence of multiple customized solutions, deployed by smaller groups of various sizes. We envision that each group forms an archipelago—an overlay of islands, where each island is a contiguous collection of ASes.1 Security derives from the mechanisms the group voluntarily deploys within the archipelago (e.g., a secure routing protocol), as well as mechanisms (that we collectively call the SBone) that provide a secure virtual topology for interconnecting the islands. Unlike the archipelago, which can deploy any security solution it wishes, the SBone is constrained to provide security on top of uncooperative, sometimes hostile, non-member ASes. We argue that this is, in fact, possible by leveraging IP-compatible mechanisms, without requiring any changes in the non-member ASes. Overlays have been a popular research topic recently, since they enable clean-slate design without the cooperation of the underlying network. Our approach differs from this past research in two important respects: An archipelago is an overlay of networks, rather than individual end hosts or servers. In traditional overlays, the participating hosts have little or no control over the ASes they connect to. In contrast, an archipelago is created by the administrators of the participating ASes. As such, the SBone nodes at island boundaries have access to the routers (and may even run directly on the routers). For example, an SBone node could switch a virtual link from one underlying path to another, in response to a failure in a non-member network. Dataplane support in the routers can substantially improve the performance and robustness of the SBone mechanisms. The SBone connects islands through virtual links with built-in security capabilities. In traditional overlays, virtual links have limited security capabilities, if any. For example, active probes used to detect performance problems are not robust to adversaries that treat probe packets preferentially. In contrast, the SBone has mechanisms for secure availability monitoring, as well as access control, confidentiality, and integrity. In the next section, we present our economic arguments for the pluralist approach. Next, we present a brief overview of the SBone, followed by several examples of archipelagos that provide secure interdomain communication. Then, we discuss related work before concluding the paper with a discussion of future research directions.